Grosse base de données et performances

Version imprimable

13/12/2006, 11h07
Promeneur

Grosse base de données et performances

Bonjour

Question de noob en grosses bases de données…

Admettons une base avec une table de 1 500 000 enregistrements de 30 ko chacun (il est possible qu’à l’avenir cela soit multiplié par 10). Les PC clients doivent se connecter dessus périodiquement pour chercher des enregistrements à traiter, par exemple 1000 enregistrements non traités. Quand ils font cela, ils marquent l’enregistrement comme en traitement, avec la date et l’heure de début. Quand ils ont fini de traiter leurs 1000 enregistrements, ils les mettent à jour dans la base centrale puis en redemandent 1000, jusqu’à ce que la totalité des documents soient traités.

Sachant que 30 clients peuvent travailler en même temps, que les clients ne doivent jamais être interrompus parce que le serveur ne suit plus, et que les clients traitent environ trois enregistrements par secondes, cela nous fait 30 connections qui peuvent être simultanées, et que le serveur envoie grosso modo 90 enregistrement par secondes en moyenne, 3 par 3 sur vers chaque client (en moyenne).

Alors voici ma question de débutant avec de grosses bases. Est-ce que c’est envisageable avec les bases actuelles ? Elles font cela et beaucoup mieux les doigts dans le nez ? Ou bien est-ce que certaines bases sont plus aptes à le faire que d’autres ?

Merci :)
13/12/2006, 14h37
fsmrel

Des sacs de patates

Bonjour Promeneur,

Votre question est très générale. Je ferai une observation : si chaque ligne de la table mesure 30 KO et si le serveur envoie 90 lignes par seconde, cela nous fait globalement 2,7 MO transférés à la seconde. Chaque PC client traite 3 lignes à la seconde donc 8 MO/seconde...

Ces chiffres sont-ils bien raisonnables ? En admettant que les connexions soient soulagées du fait d’une compression des données, au final cela fait quand même beaucoup (et vous évoquez une multiplication par 10 de ces chiffres...)

Vous parlez de documents, mais quels types de données stockez-vous ? Des images ? des chaînes de caractères et des nombres ?

Dans le premier cas, de fait, 30 KO pour une donnée élémentaire est raisonnable.

Dans le second cas, quand une ligne dépasse une centaine d’octets, on regarde de près la table pour voir s’il y a lieu de la normaliser (disons 3e forme normale), c’est-à-dire d’en faire plusieurs petites tables de taille raisonnable.

Sur ces 30 KO, combien méritent d’encombrer les connexions ? Autrement dit, combien ont vraiment besoin d’être transférés à destination des PC pour être effectivement lus (et mis à jour le cas échéant) par l’utilisateur final (humain ou programme) ? Pardonnez-moi, mais n’y a-t-il pas un peu de gabegie ? J’ai le sentiment que pour éplucher trois pommes de terre, on s’échange le sac complet...
13/12/2006, 14h38
SQLpro

LA notion d'enregistrement n'existe pas dans les SGBDR. ON parle de ligne car les donées sont écrite sur le disque par paquet qui n'ont heureusement rien à voir avec la ligne.

1 500 000 lignes cela ne veut rien dire... SI votre ligne ne comporte qu'une seule donées, mettons un entier (soit 4 octets) cela fait un volume de 6 Mo. AUtrement dit même une simple carte mémoire stick de la génération 1912.. SUfit à traiter votre base !

Un peu plus de précision serait donc bienvenu !

A +
13/12/2006, 15h00
Promeneur

Salut et merci de votre temps.

Comme je l'ai dit, chaque "ligne" pèse environ 30 ko. Quelques champs classiques (textes, date/heure, logiques) et une image. Malheureusement, toutes ces données sont nécessaires au client... Cela fait un fort volume. Actuellement, sans passer par client serveur, on fait quelque chose comme cela avec des connexions TC/IP, sur un prototype, et 30 clients. Mais je voudrais examiner plusieurs solutions, y compris une liaison client serveur classique.
13/12/2006, 15h25
Invité

Indépendamment du SGBDR, le débit réseau sera primordial pour votre besoin.
14/12/2006, 10h32
Promeneur

Citation:

Envoyé par kuzco

Indépendamment du SGBDR, le débit réseau sera primordial pour votre besoin.

Partons de l'hypothèse que l'infrastructure matérielle sera adaptée à nos besoins.
14/12/2006, 12h54
SQLpro

SI vous voulez des performances il est préférable de ne pas mettre d'images et en général tous type d'objet se traduisant in fine en fichier dans une base de donées :
- vous augmentez artificiellement le volume des données à manipuler dans la base
- les BLOBS doivet être réinstancié sous forme de fichiers.

Donc prévoyez plutôt de les stocker dans un serveur de fichier.

LIsez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/stockerimages/

A +
14/12/2006, 15h15
Promeneur

Citation:

Envoyé par SQLpro

Donc prévoyez plutôt de les stocker dans un serveur de fichier.

LIsez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/stockerimages/

Très intéressant article, SQLpro, merci !
14/12/2006, 17h43
Mat.M

Attention il ne faut pas seulement prendre en compte la taille de la BDD; mais aussi la manière dont les traitements via requêtes SQL sont effectués.
Il va s'en dire que par exemple plus on délégue au moteur de BDD les traitements ( procédures stockées...) plus les performances seront accrues
15/12/2006, 13h56
vmolines

Citation:

Envoyé par SQLpro

SI vous voulez des performances il est préférable de ne pas mettre d'images et en général tous type d'objet se traduisant in fine en fichier dans une base de donées :
- vous augmentez artificiellement le volume des données à manipuler dans la base
- les BLOBS doivet être réinstancié sous forme de fichiers.

Donc prévoyez plutôt de les stocker dans un serveur de fichier.

LIsez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/stockerimages/

A +

Que pensez-vous de l'utilisation du partitionnement (vertical et/ou horizontal) afin de conserver l'homogénéïté qu'apporte l'utilisation des blobs et de résoudre une partie des problèmes de performance qu'ils peuvent engendrer ?

Votre article traite d'une des solutions possibles (traiter des liens vers un système de fichier) et j'aurais avoir des avis sur cette autre approche.
25/04/2007, 00h03
GyLes

Avez-vous penser à l'utilisation d'un SGBDO ?

Un SGBDO travaille sur des transactions longues en utilisant le cache côté client.
Le client peut ainsi récupérer 1000 enregistements, les travailler localement sur sa machine tout en ayant sécuriser les enregistrements (gestion concurrence, transactions, ...) et renvoyer le paquet au serveur une fois le traitement effectué.

Les SGBDOs permettent justement ce type de traitement et sont adaptés aux transactions longues de gros paquets de données.

En fonction du contexte, peut-être une piste à explorer ?
26/04/2007, 16h58
fsmrel

Citation:

Envoyé par GyLes

Un SGBDO travaille sur des transactions longues en utilisant le cache côté client.

C'est très bien. Mais comment fait-on s'il faut, côté serveur, une heure au SGBDO pour collecter les données à destination du client ? Sans parler du temps qu'il doit consacrer aux mises à jour...

Puisque le thème de la discussion est "Grosse base de données et performances", je m'intéresse évidemment ici à des bases de données composées de tables (ou équivalent) dont certaines ont une volumétrie dépassant les cent millions de lignes (pour en moyenne une centaine d'octets par ligne).
26/04/2007, 18h13
GyLes

Vous sous-estimez les SGBDOs pour leur donner une heure pour récupérer 1000 enregistrements. Une base de données est un conteneur de données, pas forcément sous forme de table.

Les SGBDOs sont optimisés pour des applications d'ingénierie. Le traitement de gros plans de milliers de pièces est un exemple.
27/04/2007, 02h40
fsmrel

Bonsoir GyLes,

Vous écrivez :

Citation:

Vous sous-estimez les SGBDOs pour leur donner une heure pour récupérer 1000 enregistrements

Loin de moi l’idée de sous-estimer les possibilités de récupérer mille "enregistrements" de la part d’un SGBDO. J’émets seulement des réserves — et ceci vaut également pour les SGBD relationnels ! — quand recueillir un, dix, mille ou un million d’enregistrements implique de balayer dans tous les sens des espaces-disques gigantesques, avec des entrées-sorties à l’infini. Les 1000 enregistrements que vous évoquez correspondent pour moi non pas à 1000 accès (disque ou mémoire) mais au résultat disons d’une requête au sens relationnel du terme, ayant nécessité 10 exp N accès physiques, N pouvant varier entre 2 et 18... Peut-être n’avons-nous pas la même perception du mode de recueil des données : je ne recherche pas moi-même les 1000 enregistrements un par un, je demande au système relationnel, par le biais de cette requête, de me fournir un résultat qui soit une table (au nom du principe de fermeture) et dont j’extrairai finalement chacune des 1000 lignes, par exemple pour les transmettre à un autre traitement qui ne manipule pas de tables ou pour les imprimer, etc.

J’ai passé énormément de temps dans les entreprises à rendre performantes des applications utilisant des SGBDR, souvent en catastrophe, avec une casquette "docteur des bases" (sic). Autant on a peu de surprises avec un SGBD pré-relationnel en termes de performances (je l’ai vérifié pendant des années), autant avec un SGBDR, si l’on n’a pas modélisé correctement, c’est généralement la catastrophe et c’est rédhibitoire quand le projet revêt une certaine ampleur. Et si l’on a modélisé correctement, il reste à procéder à certains réglages (réorganisations, choix des index, mise à jour des statistiques du catalogue relationnel, campagnes dites d’explain) pour obtenir des temps de réponse et des durées de traitements batch satisfaisants, répondant au cahier des charges ayant conduit à bâtir des prototypes de performance et toutes ces sortes de choses. Si l’on ne procède pas à ces réglages, les temps de traitement peuvent être infinis (généralement pour cause de produits cartésiens), mais au contraire, si le DBA a fait son travail, on est souvent impressionné par la vitesse à laquelle les résultats sont obtenus (« Chef ! ça va trop vite, il doit y avoir une erreur ! »).

Concernant les SGBDO, il ne m’a pas été donné l’occasion de les chahuter, contrairement aux autres SGBD et je le regrette vivement. Une question : avec un SGBDO, la performance d’un traitement est-elle relativement facile à prévoir, ou bien faut-il mettre en oeuvre, comme dans le cas des SGBDR, des réglages minutieux pour éviter que les temps de traitement tendent vers l’infini ?

Citation:

Les SGBDOs sont optimisés pour des applications d'ingénierie. Le traitement de gros plans de milliers de pièces est un exemple

Je vous l’accorde bien volontiers. J’ai échangé il y a une douzaine d’années avec quelqu’un qui faisait dans l’accidentologie et utilisait un SGBDO : cette personne était emballée car si le sujet n’était pas simple, son SGBD lui était d’une aide essentielle et elle ne jurait que par lui. Elle traitait environ 30000 objets complexes et je pense que je n’aurais pas été capable de les manipuler avec mon SGBDR "généraliste", lequel ne permettait pas que l’on définisse ses propres types (classes).

Pour ma part, je suis plus habitué à des thèmes relativement simples, disons orientés "gestion". Les volumes sont souvent énormes. Imaginez par exemple, chez tel ou tel opérateur, la collecte ad nauseam des trames téléphoniques, de structure simple, mais qui se présentent par millions tous les soirs déversés par les autocommutateurs et qu’il faut exploiter au plus tôt (les nuits sont courtes...) Songez encore aux 40 années de cotisation des adhérents qu’il faut conserver (en ligne) dans les caisses de retraite, etc. Les traitements sont évidemment beaucoup plus simples par rapport à ceux qui se rapportent à l’accidentologie ou aux plans que vous évoquez, mais il y a quand même des problèmes non triviaux qui se posent en relation, par exemple, avec la prise en compte du temps, ou tout simplement avec des aspects algorithmiques que l’on peut fort heureusement sous-traiter au SGBDR (ne serait-ce que ceux, basiques, relevant des "appareillages de fichiers") qui se révèle être un algébriste, un analyste et un développeur sans pareil.

Je ne cherche pas à critiquer pour critiquer, ainsi les concepts OO de classe et d’héritage sont essentiels et manquaient au Modèle relationnel d’origine qui s’appuyait sur des types simples, parce qu’à l’époque cela suffisait. Depuis, on a assisté à une certaine évolution. Évidemment, quand il y a 20 ans, le professeur Gardarin et ses collègues ont créé Sabrina, ils ne pouvaient se contenter de types simples, alors que leur système était un système de gestion de bases de données relationnelles. S’ils avaient entrepris leurs travaux dix ans plus tard le qualificatif orienté objet eût à coup sûr remplacé celui de relationnel.

En revanche, je reste dubitatif concernant l’apport du concept d’OID. Au niveau physique, L’OID permet-il par exemple de minimiser l’effet I/O bound, en regard des 10 exp N accès disque possibles, quand N prend une valeur importante ? Au niveau conceptuel, dispense-t-il de définir des clés candidates, permettant entre autres à l’utilisateur d’accéder à un objet en particulier ?

J'ai vu que vous aviez répondu à un autre message. Je ne manquerai pas de l'étudier. Sans doute des questions-réponses s’entrechoquent-elles, mais ça n'est pas bien grave...
27/04/2007, 11h28
SQLpro

Force est quand même de constater que les SGBDO ont quasiment disparus au profit des SGBDR en raison justement des mauvais performances générales des SGBDO...
De même les langages purement objet (SmallTalk en est un bon exemple) on fait un flop, car on fait plus d'aditions basiques que d'opérations sur des objets dans la plupart des traitements.
C'est pourquoi aujourd'hui les SGBDR comportent une petite partie O afin de satisfaire les deux mondes sans perdre de vue le point essentiel, la performance face aux volume des données.

A +
27/04/2007, 14h08
GyLes

Les SGBDOs offrent des mécanismes d'optimisation qui leurs sont propres. Le regroupement de données en est un exemple, permettant d'optimiser l'emplacement des objets en relations les uns avec les autres dans un espace disque proche. Les problématiques de conception restent les même que dans un SGBDR. Le SGBDO ne connaît pas la sémantique des données/objets contenus dans la base. C'est au développeur de lui donner la sémantique et le paramétrage/développement nécessaire à l'optimisation tout comme dans les SGBDR pour la création des index. C'est par exemple le cas pour le regroupement.

L'OID et les techniques d'optimisation, de génération de ces OIDs offrent de très bonnes performances. Il existe différentes implémentation de ces OIDs et diverses avantages / inconvénient liés. Les bases de données réparties est un exemple de l'avantage des OIDs. Un SGBDO sait concaténer l'identifiant d'une machine réseau à un OID, permettant ainsi à l'objet de voyager sur le réseau de machine en machine et de manière transparente pour l'utilisateur.
Un OID unique, un OID suppléant, un OID avec identification du type, vont offrir des performances différentes mais des fonctionnalités supplémentaires.

Les techniques de swizzling permettant de convertir les OIDs en pointeurs mémoires permettent à un ensemble d'objets en relation d'être vus comme une structure de données en langage C (uniquement des pointeurs mémoires, et donc pas de traitements supplémentaires).

Concernant les performances, les benchmarks OO1 puis OO7, et enfin le produit open source polepos (sur sourceforge) offrent des analyses de performances entre un SGBDR, SGBDO, SGBDRO et mapping, selon le type de requêtes et le type d'application que l'on en fait.

Objectivity, Object Store, Versant, Matisse, Caché, db4o, .... sont autant de SGBDO qui font vivre leurs sociétés. Db4o offre d'ailleurs un intérêt accru vue le nombre de publications sur le net et dans les magasines.

Je ne pense pas que les SGBDOs soient "presque" disparus. On les attendait peut-être sur un domaine qui n'est pas forcément le leur. Un SGBDR restera toujours (je pense) bien plus performant qu'un SGBDO en terme de traitement de transactions courtes et rapides.

Un point sur lequel je m'étais focalisé au début de mes recherches, je pensais que les SGBDOs étaient la solution pour l'aspect dysfonctionnement des langages. Nous parlons des performances d'un SGBDR, performances brutes lors de traitement par procédures stockées sur le serveur. Quand est-il des problématiques de plus en plus courantes de l'utilisation d'un langage objet couplé à un SGBDR, et des dysfonctionnements des deux langages nécessitant de fortes conversion de types de données, et des mapping entre deux mondes très différents (objets et tables) qui diminuent fortement les performances globales, donc performance de l'application, qui est finale la plus importante car visible par l'utilisateur. Que faire d'un SGBDR qui peut répondre en un minimum de temps à une requêtes si il faut derrière moultes traitements, conversion de données pour offrir l'information finale à l'utilisateur ?

Le début de succès de Db4o me donne l'impression qu'il a su très bien se positionner sur cette problématique: Développez en OO sans les problèmes de mapping Hibernate, JDO ou autres. Pas de problèmes de dysfonctionnement, langage de programmation auquel on a ajouté les principes d'une base de données (transactions, concurrence, langage de requêtes, relations, intégrité référentielle, ...). Db4o par contre n'offre pas pour l'instant tous les avantages d'un SGBDR. Mais pourquoi comparer ? Un SGBDO répond à une problématique, propre pour l'instant aux applicatins d'ingénierie (mécanique, électronique, aéronotique), aux applications bureautiques, aux applications embarquées (exemple de BMW).

Je ne crois pas pour l'instant dans un produit unique qui sache résoudre les problématiques solutionnées par les SGBDR et les SGBDOs, et ne crois pas non plus qu'un SGBDO remplacera un jour un SGBDR dans le domaine des applications de gestion classique.

Pas de mauvaise critique, pas de soucis, mais un bon topic permettant de confronter les idées de chacun et de lever certaines idées reçus aussi ;)
29/04/2007, 01h48
fsmrel

Citation:

Un SGBDR restera toujours (je pense) bien plus performant qu'un SGBDO en terme de traitement de transactions courtes et rapides.

Pour des transactions lourdes correctement réglées (par exemple impliquant un parcours récursif de nomenclatures de centaines de milliers de lignes), un SGBDR comme Oracle ou DB2 peut aussi être redoutable. Même chose pour les batchs exploitant des tables dont la volumétrie dépasse les cent millions de lignes.

Quant au dysfonctionnement des langages, parce que les applications de gestion manipulent des structures simples, sous forme de tuples, la conversion ne coûte pas cher : personnellement se sont les entrées/sorties qui ont toujours sollicité mon attention (en relation avec ce que j’ai écrit dans le précédent paragraphe). Mes collègues DBA devraient confirmer.
14/05/2007, 14h36
GyLes
La conversion entre les deux mondes Relationnel / Objet coûte très cher. Les mappeurs comme Hibernate consomme un temps de traitement non négligeable (problématique de l'impedance mismatch).

Je ne parle naturellement pas des batchs de traitements directement exécutés sur le serveur de données par exemple, mais bien des applications avec interface utilisateur interrogeant la base de données. Nombre d'applications utilisent aujourd'hui des langages objets (Java, .Net, ...) avec une base de données relationnelle. La conversion entre ces deux mondes passent par un mappeur comme hibernate. C'est ici qu'intervient une partie de perte de performance.

Le SGBDO intègre directement le langage de programmation natif (pas de modification du langage hôte, C, Java, .Net) et les concepts de bases de données. Pas de problème de dysfonctionnement des langages, pas de problématique d'impedance mismatch.

Pour revenir sur l'optimisation des SGBDOs, le SGBDO offre deux moyens d'accéder aux données de la base. Via un langage de manipulation de données (OML selon la norme ODMG), ou via un langage de requêtes non procédurale OQL.

OQL est capable de réaliser l'équivalent de la jointure relationnelle. Les valeurs de jointures (valeurs de champs) sont remplacées par des pointeurs. Le principe reste cependant le même.

L'optimiseur d'un SGBDO est par contre bien plus complexe que l'optimiseur d'un SGBDR. Il doit prendre en compte les nouveaux types créés par l'utilisateur, les nouvelles opérations de comparaison propre aux types de données nouvellement définis, des méthodes spécifiques, ... sans compter les nombreuses possibilités d'accéder à la même données via le parcours de chemins, il faut aussi prendre en compte les collections, les structures de données.

Plusieurs mécanismes permettent l'optimisation des SGBDOS:
- Index classiques
- Regroupement d'objets
- Objets liés ou encastrés
- Index de chemins
- Index de collections
- Modèle d'évaluation des méthodes utilisateurs

L'optimiseur se base sur le même principe qu'un optimiseur en relationnel:
1. Générations de plans équivalents utilisant des statistiques
2. Stratégie de recherche du meilleur plan (algorithme combinatoire itérative, du recuit simulé, optimisation en deux phases, recherche taboue, algorithme génétique ...
Ci-dessous un petit lien sur les résultats donnés par Polepos, le framework de benchmark pour les bases de données.
http://polepos.sourceforge.net/results/html/index.html

Les résultats permettent de comparer les actions de création, suppression et de lecture d'objets non structurés, structurés, en arbre, ....

Les SGBDOs restent dans la course, ils ont leur marché de niche. Un petit lien sur les success stories de Objectivity, pour ne citer que celui ci:
http://www.objectivity.com/pages/dow...essstories.asp
15/05/2007, 13h56
GyLes

Un petit lien sur le site de Caché Expert concernant une étude de KLAS sur les bases de données utilisées dans le milieu médical:

http://www.cache-expert.com/docs/klas-intersystems.pdf
16/05/2007, 02h35
fsmrel

Citation:

Un petit lien sur le site de Caché Expert concernant une étude de KLAS sur les bases de données utilisées dans le milieu médical

J'ai déjà assisté à ce genre de film. Que voulez-vous que je pense de la pertinence d'un article mettant en comparaison deux systèmes, signé par le fournisseur de l'un d'eux, qui s'avère comme par hasard le meilleur ? Je suis un technicien, pas un commercial.

Le sondeur ne compare pas des SGBD mais des applications, puisqu'il s'adresse aux utilisateurs. Ceux-ci connaissent le domaine de la santé, point barre. Quand ils disent que leur base de données est tombée en panne, ils parlent en réalité de leur application, puisqu'ils n'ont pas la connaissance de ce qui se trouve sous le capot. Que les applications soient à mettre au point, certes, mais si Oracle tombait aussi souvent en panne, ça se saurait.

Selon l'article : "Le sondage de KLAS comportait plusieurs questions destinées à mesurer la complexité de l’utilisation des applications sur les sites de gestion des dossiers médicaux".

Sont-ce les programmes ou les SGBD qui sont en cause ? Et même s'il s'agissait des SGBD, étaient-ils correctement réglés, les tables normalisées ? Etc.

On amalgame et on file vers le sophisme.

Ces gens auraient fait leur sondage chez des utilisateurs exclusivement d'un des deux SGBD, en les répartissant en deux groupes, je suppose que les points auraient été attribués dans les mêmes proportions et donc que le SGBD serait meilleur que lui-même.
16/05/2007, 08h58
GyLes

Citation:

Et même s'il s'agissait des SGBD, étaient-ils correctement réglés, les tables normalisées ? Etc.

C'est un argument qui peut être repris pour les SGBDOs tant critiqués ;) Il y a aussi des règles de l'art à appliquer.

Encore une fois, je ne rentre pas dans un combat de comparaison entre SGBDR et SGBDO, cela ne m'intéresse pas des plus, c'est l'ouverture vers ses systèmes, leur domaine d'application et leurs avantages qui m'intéressent.

Citation:

On amalgame et on file vers le sophisme.

Etudions dans ce cas les avantages des SGBDOs dans leur domaine d'application, et arrêtons les critiques des plus simples comme "Les SGBDOs ne sont pas performants, obsolètes et inutiles, les SGBDRs sont les meilleurs, un point c'est tout". Ce type de discussion n'est pas très constructive.

Je serai bien plus heureux d'échanger de manière constructive la-dessus. Donnez moi une étude, un article, ... quoique ce soit qui montre l'utilisation d'un SGBDR dans les domaines d'application d'un SGBDO. Que le SGBDR dans ce domaine dépasse de loin les performances, la fiabilité et les avantages des SGBDOs.

Je vous ai donné quelques uns des domaines d'applications des SGBDOs, et c'est dans ces domaines qu'ils se montrent les plus utiles (Ingénierie, bureautique, base de données embarquées, génie logiciel, ...).

Je ne suis pas venu sur le topic en lancant que les SGBDRs étaient dépassés, et vive les SGBDOs. J'ai uniquement ouvert la voie vers une utilisation possible d'un SGBDO. Pourquoi pas ?

Je n'ai rien contre vous fsmrel, j'ai lu quelques uns de vos postes et j'en respecte le contenu. Ne rentrons pas dans une discorde de propos.

Votre réactions sur mon précédent poste m'auraient plus intéressé que votre remise en question sur une étude (sur quelles études se baser alors, il ne me semble pas que KLAS soit un fournisseur de SGBDOs d'ailleurs ).
http://www.healthcomputing.com/

Que pensez-vous des mécanismes d'optimisation similaires aux SGBDRs ? Des spécificités des optimiseurs ? Des benchmarks OO1, OO7 ou polepos qui comparent directement quelques SGBDRs avec mapping et un SGBDO (db4o pour le moment) ? Avez-vous lu les succes stories de Objectivity par exemple ?

Cordialement,
Gilles
17/05/2007, 17h07
fsmrel

Bonsoir Gilles,

Citation:

Votre réactions sur mon précédent poste m'auraient plus intéressé que votre remise en question sur une étude (sur quelles études se baser alors, il ne me semble pas que KLAS soit un fournisseur de SGBDOs d'ailleurs).

Certes, mais je ne suis pas resté insensible à cette étude à laquelle vous renvoyez, à l’occasion de votre dernier message. Ce que j’ai écrit ne visait pas les SGBD quels qu’ils soient, mais les conclusions de ce sondage dont Coluche aurait pu s’inspirer (lessive machin contre lessive truc). Ce genre d’étude comparative a le don de m’énerver, ça valait un message d’avertissement à usage général. J’ai trop rencontré de ces prétendus experts qui ont bâti leur compétence en collectionnant ce genre de conclusions subjectives, bien habillées, pendant que de mon côté j’étais dans la soute à faire marcher la machine (ne prenez pas cela pour vous).

Citation:

je ne rentre pas dans un combat de comparaison entre SGBDR et SGBDO

Moi non plus ! Comparer, je faisais ça quand j’étais jeune, mais sérieusement, avec les SGBD en main et sous le contrôle de qui de droit, comme je l’ai déjà dit. Cela motive aussi mon agacement à l’endroit du sondage évoqué.
Souvenez-vous de ce que j’ai écrit à propos de cette personne dont le sujet était l’accidentologie et ne jurait que par son SGBDO : je ne pensais pas que j’aurais été capable de faire aussi bien avec mon SGBDR "généraliste" (mon message du 27/04/2007). Il eut été stupide de ma part de chercher à la convaincre de changer.

Citation:

Etudions dans ce cas les avantages des SGBDOs dans leur domaine d'application, et arrêtons les critiques des plus simples comme "Les SGBDOs ne sont pas performants, obsolètes et inutiles, les SGBDRs sont les meilleurs, un point c'est tout".

Une fois de plus, je ne fréquente pas le café du Commerce. Je ne critiquerai jamais gratuitement ni ne ferai l’éloge d’un SGBD que je ne connais pas, qu’il soit R, O, mixte, américain, français, martien ou autre. Tout au plus fais-je telle ou telle observation à propos de telle ou telle fonctionnalité importante sur laquelle je m’interroge, par exemple : comment garantit-on l’intégrité référentielle autrement que par programme ? Comment est définie la métabase et comment y a-t-on accès ? La théorie de la normalisation a-t-elle un sens ? Etc.

Je répète donc que je ne juge pas, contrairement à ce que vous laissiez entendre dire :

Citation:

Citation:

Vous sous-estimez les SGBDOs pour leur donner une heure pour récupérer 1000 enregistrements

Loin de moi l’idée de sous-estimer les possibilités de récupérer mille "enregistrements" de la part d’un SGBDO. J’émets seulement des réserves — et ceci vaut également pour les SGBD relationnels !

=> Je ne critiquerai jamais un SGBD quel qu’il soit sans l’avoir secoué sur le terrain. Est-ce clair ?

Citation:

Je ne suis pas venu sur le topic en lancant que les SGBDRs étaient dépassés

De fait, ceux qui, par exemple, font la promotion de Caché sont là pour ça, mais il ne fallait pas me mettre leur article sous les yeux.

Citation:

Que pensez-vous des mécanismes d'optimisation similaires aux SGBDRs ? Des spécificités des optimiseurs ? Des benchmarks OO1, OO7 ou polepos qui comparent directement quelques SGBDRs avec mapping et un SGBDO (db4o pour le moment) ?

Je pense que du temps où je passais mon temps dans la soute, j’aurais étudié tout cela très sérieusement. Aujourd’hui, je préfère dire que je n’en pense rien, parce que ça relève plutôt de la technologie, donc avec le temps ça devient vite obsolète et ça se remplace : je préfère la réflexion portant sur les fondements, parce qu’ils sont intemporels, ils sont au dessus des technologies. Quand vous relirez dans dix ou vingt ans les articles techniques d’aujourd’hui, il y a de fortes chances que vous trouverez que ça aura bigrement vieilli, même si ça sera avec nostalgie. Ainsi, Je ne connais pas ce logiciel Hibernate que vous évoquiez, mais d’une façon ou d’une autre, s’il a une espérance de vie suffisante, il aura résolu ses problèmes actuels (ou d’autres s’en seront chargé...)
Le Modèle Relationnel de Données a ma faveur parce qu’il est solidement ancré dans la logique des prédicats sans être pour autant figé, on y parle d’ensembles et de prédicats plutôt que de pointeurs et quand je relis ce que Codd a écrit il y a trente-cinq ans, je constate que les fondements n’ont pas bougé, ce qui n’a pas empêché des évolutions, qui du reste continuent aujourd’hui (à l’instar de la logique, qui n’a jamais été remise en cause depuis Aristote mais s’est enrichie avec Frege et ses successeurs). A l’occasion, j’essaie d’en faire profiter les autres, en essayant de leur parler de la Théorie relationnelle, quitte à descendre au niveau de la technologie relationnelle quand cela s’avère nécessaire. Et puis la théorie relationnelle est particulièrement utile pour s’assurer de la validité d’un diagramme entité/relation ou d’un diagramme de classe (normalisation). Mieux on est équipé, mieux c’est...
26/09/2007, 11h09
mhoudas

SGBDO vs SGBDR une vieille histoire

Les premiers SGBDOs industriels ont vus le jour il y a plus de 12 ans, de cette génération il ne reste plus que Versant et (Poet) et dans une mondre mesure ObjectStore et Objectivity. Pour rappel Caché n'est pas vraiment un SGBDO mais une base de type NF2 (base de données de type Unidata ou VMark)Pourtant l'approche objet s'est imposé tant au niveau des langages que des méthodes et des produits ou frameworks, seul le stockage reste relationnel et le restera encore surement tres longtemps. Les critères de performance et de transpartence de la persistence (productivité en phase de développement et de maintenance) mis en avant par les éditeurs de SGBDO sont notoirement insuffisants pour faire basculer le marché et les retours d'expérience ne sont pas suffisament satisfaisants. Pourtant les performances peuvent être au rendez-vous, en effet un SGBDO est un SGBD réseau structuré par un modèle objet et il est évident que la navigation (pointeur) est plus rapide que la jointure (algo de trie) encore faut-il que les chemins soient prévus. Un SGBDO est donc bien adapté en terme de performance aux modèles complexes (beaucoup derelations entre classes et/objet) et peu aux applications de gestion traditionnelles. La performance va aussi dépendre du type d'applications (transactionnelle ou non, nombre d'objets, taille des objets) et de l'implémentation interne du SGBDO dans des proportions que l'on ne retrouve pas aujourd'hui entre les divers SGBDR sdu marché.
La transparence de la persistence est plus un argument marketing pour les grosses applications et va dépendre énormement des choix d'implémentation au niveau du produit (serveur d'objets, serveur de pages, granularité du verrouillage(objet vs page), modèle transartionnel (optimiste, pessimiste,transactions longues, transactions imbriquées, modèle objet du SGBDO lui-même).
Quelques problèmes liés à l'adoption des SGBDOs:
1) Manque de standard (L'ODMG (Binding C++ et Java, OQL) est plutôt un échec, SQL3 n'est pas objet et est complexe;
2) Interopérabilité entre les langages (C++ persistent, java persistent, modèle neutre (type O2C)
3) Evolution du schéma versus Modèle de classe de l'application à mettre en relation avec la problèmatique des vues
4) Langage de requêtes et optimiseur
5) Outils (les outils fonctionnent avec un SGBDR pas un SGBDO)
6) Administration et exploitation
7) Formation
8) Perennité
26/09/2007, 17h43
fsmrel

Bonjour mhoudas,

Je ne vous suspecte pas de favoriser outre mesure une classe de SGBD, mais manifestement vous exprimez des regrets... Cela dit, je souhaite commenter certaines de vos affirmations.

Citation:

un SGBDO est un SGBD réseau structuré par un modèle objet et il est évident que la navigation (pointeur) est plus rapide que la jointure (algo de trie)

C’est du 2e degré ?

J’ai utilisé, chahuté des SGBD bourrés de pointeurs dans tous les sens entre 1970 et 1985 (IMS/DL1, IDMS, TOTAL, etc.) sur de très grandes bases de données. C’était l’époque héroïque, et nous proclamions : navigation par pointeurs = puissance absolue. Et puis j’ai utilisé DB2. Il y a maintenant 20 ans, j’ai pris la peine de passer près de deux cents nuits sur un mainframe à le comparer en termes de performance avec un champion « réseau » : ça m’a permis de confondre son promoteur français qui tirait à boulets rouges sur DB2, clamant en toute méconnaissance de cause que c’était une brouette (marketing oblige). Manque de chance, non seulement je connaissais très bien le SGBD réseau concerné, j’avais aussi appris à maîtriser DB2. J’ai prouvé au détracteur que, mal utilisé, DB2 pouvait aller 1000 fois trop lentement (à cause des produits cartésiens et autres facéties) mais qu’utilisé normalement (c'est-à-dire dans l’esprit ensembliste), c’était une bombe, allant au bas mot 10 fois plus vite que son champion. La performance d’un système réseau est à peu près constante, il n’y a pas de surprise. Au contraire, un SGBDR digne de ce nom, c’est comme une Ferrari : mal réglé, c’est une catastrophe, mais entre des mains compétentes, il laisse les SGBD non relationnels sur place. La clé : lui faire confiance (s'il le mérite !) et lui sous-traiter la programmation, le comment, le procédural, et ne lui présenter que le quoi, sous la forme d’un prédicat (« Donne-moi les noms des clients qui n’ont pas réglé leur cotisation depuis telle date et qui sont déjà fichés à la banque centrale avec un risque en trésorerie supérieur de 10% à la moyenne nationale »). L’optimiseur du SGBDR (inévitablement de plus en plus puissant au fil des versions) prend donc la programmation en charge, il l’encapsule pour utiliser un mot à la mode. Clairement, un SGBDR n’est pas un quelconque outil de stockage et, tel le bœuf moyen, auquel on ne demande pas de réfléchir ! Regardez Oracle, ce fut une brouette mais aujourd’hui vous ne pouvez qu’être impressionné quand vous constatez qu’il lui faut moins de 100 millisecondes pour traiter (récursivement bien entendu) une nomenclature de 150 000 lignes avec jointure avec d’autres tables à la clé, à partir d’une requête comportant 5 ou 6 lignes (10 millisecondes demain ?)... L’intérêt des SGBDR est qu’au lieu de vouloir nous intéresser aux cacahuètes les unes après les autres (pointer chasing), nous pouvons nous intéresser uniquement au sac qui les contient, quitte en fin de parcours à présenter les cacahuètes "résultat" aux utilisateurs, une par une, dans l’ordre qui fait plaisir à ces derniers (comme dans le cas de la nomenclature évoquée). Évidemment, si l’on n’adhère pas à l’esprit ensembliste, on peut en rester à une culture séquentielle et considérer un SGBDR comme un vulgaire outil de stockage, mais alors cela n’offre pas plus d’intérêt que de se mettre au volant d’une Ferrari et de rester en première...

Dans le même sens, c’est quoi cette histoire « d’algo de trie » ? Encore une fois, la cuisine au niveau physique doit rester sous le capot. Pour parler vulgairement, le tri on s’en tape, ça n’est pas notre problème, mais celui du SGBD. Je crois que vous confondez le niveau logique et le niveau physique. Si le SGBD a besoin de trier, qu’il le fasse, parce qu’indirectement on l’y force (ORDER BY, GROUP BY, DISTINCT, UNION, etc.) et qu’aujourd’hui c’est sa technique, ou parce qu’il n’a pas les bons index pour optimiser la durée de l’opération de jointure, mais parler d’algorithme de tri dans un contexte relationnel est une pétition de principe totalement gratuite. Quand tris et index, auront été remplacés par d’autres technologies, nos requêtes SQL (ou QUEL, QBE, D, etc.) n’auront pas à être modifiées (voyez par exemple le TranRelational Model de Steve Tarin, modèle dans lequel TransRelational signifie transformation et qui agit non pas au niveau logique, mais plutôt physique).

Citation:

encore faut-il que les chemins soient prévus.

Ben oui. Je pense que l’approche OO est en cause. Par contraste, un des soucis de Ted Codd, père du Modèle Relationnel de Données était de celui de la symétrie : quel intérêt à favoriser telle ou telle requête au détriment de telle autre ? Un système relationnel doit être équilibré et équitable. Du fait de son caractère associatif par valeurs prises par les attributs des tables, son modèle ne privilégie effectivement aucun « chemin » (mot qui est donc sans signification avec le Modèle relationnel).

Citation:

La performance va aussi dépendre du type d'applications (transactionnelle ou non, nombre d'objets, taille des objets) et de l'implémentation interne du SGBDO dans des proportions que l'on ne retrouve pas aujourd'hui entre les divers SGBDR sdu marché.

Allez explorer l’optimiseur de DB2, vous m’en direz des nouvelles. Cela dit, je suis d’accord que SQL est devenu monstrueux par sa corpulence et ses verrues et qu’il ferait bien de se recaler sur la théorie relationnelle, avec un bon lifting, un bon coup de rasoir d’Occam, pour que les optimiseurs des SGBDR puissent travailler sur des concepts parfaitement orthogonaux et fonctionner vraiment plein pot (en l’occurrence, orthogonalité veut dire indépendance, donc puissance).

Bien entendu, il y a d’autres éléments que le SGBD lui-même à prendre en compte pour qu’une application percute, sinon ça serait magique. Suite à la mauvaise performance des applications, j’ai audité bien des modèles de données. Ces modèles avaient été généralement concoctés par d’aimables amateurs qui auraient mieux fait de s’occuper d’autres choses. Mais ceci est une autre histoire...
02/10/2007, 15h42
mhoudas

bonjour FMSREL,
Je vois que vous avez une grande expérience de DB2 après avoir utilisé les SGBD réseau. Avez-vous déjà utilisé une SGBDO et aujourd'hui feriez-vous l'effort que vous avez fait quand vous êtes passé du modèle réseau au modèle relationnel, êtes-vous pret à faire l'effort d'un apprentissage equivalent à l'apprentissage du langage SQL et des formes normales ?

J'ai travaillé chez des éditeurs de SGBD tant relationnel qu'objet pendant une dizaine d'années plus particulièrement au niveau moteur et architecture ce qui permet de comprendre ce qui se passe réellement derrière une requête SQL ou au travers d'un langage objet. La vision ensembliste est naturelle dans l'approche relationnelle au niveau d'un utilisateur mais ce n'est pas du tout celle qui faut avoir pour utiliser un SGBDO de façon efficace, il faut avoir une vision objet où autrement dit un modèle objet.

Je ne suis pas un partisant ou un ennemi des SGBDRs ou des SGBDOs. J'ai participé à de nombreux benchmarks clients au gré de ma carrière portant tour à tour les couleurs d'Oracle, d'IBM puis de Versant et d'O2 avant de revenir chez IBM. il n'y a pas un vainqueur définitif entre ces produits sur le plan des performances. Les SGBDOs ont toujours eu un avantage sur les modèles complexes (modèle de type graphe ou arborescence) avec souvent des rapports de 10 à 100 voir plus de 1000 par contre sur des modèles simples (la majorité des applications) la tendance peut être différente.

Oui les performances des SGBDRs augmentent mais essentiellement comme la puissance des serveurs qui les supportent cela est vrais pour tout les produits. logiciels

Enfin l'utilisation d'un SGBDO n'a de sens qu'associé à l'utilisation d'un langage objet tel que C++ ou Java. L'utilisation de SQL avec un SGBDO n'a aucun sens et l'absence d'un langage de requête objet standard (OQL) est un véritable problème qui limite surement l'utilisation des SGBDO (voir mon post précedent).

La taille des bases de données reposant sur un SGBDO est en général relativement faible (quelques GO) à l'exception des bases de données reposant sur Objectivity (archivage des données collectéres sur les acélerateurs de particule) où on arrive un volume de données de l'orde du peta-octet mais il s'agit là uniquement d'archivage, pour Versant la plus grosse base est une base de données d'empreintes digitales réalisé par SAGEM-Morpho (environ 600 GO) et pour O2 des bases de l'ordre de 8 GO pour une compagnie d'assurance suisse.
02/10/2007, 21h08
fsmrel

Bonsoir MHOUDAS,

Citation:

Envoyé par mhoudas

Avez-vous déjà utilisé une SGBDO et aujourd'hui feriez-vous l'effort que vous avez fait quand vous êtes passé du modèle réseau au modèle relationnel, êtes-vous pret à faire l'effort d'un apprentissage equivalent à l'apprentissage du langage SQL et des formes normales ?

Désolé, je n’ai pas utilisé de SGBDO et j’avoue que je n’aurai plus le courage de me lancer dans l’apprentissage d’un SGBD de quelque type que soit, de plonger dans C++ ou Java. J’ai commencé par l’assembleur bien mis en oeuvre le triplet Seek/Search/TIC, le Rotational Positioning Sensing (si vous êtes chez IBM, ça doit vous causer), pour faire percuter l’accès aux données, à l’opposé je suis passé par Prolog, j’en suis arrivé à la table de cardinalité 1 et de degré 0 (une ligne et zéro colonne), maintenant je pose le sac (Au passage, j’ai réécrit TOTAL il y a un peu plus de trente ans, pour le compte un client qui trouvait que son SGBD n’allait pas assez vite...)

Concernant SQL, l’effort ne fut pas bien grand, car une fois qu’on a compris le Modèle Relationnel de Données, cet avatar qu’est SQL s’apprend facilement, à ceci près qu’il est agaçant, qu’il a un comportement parfois bizarre et que je m’en méfie. SQL n’est pas le relationnel et comme je l’ai écrit dans un précédent message, c’est un monstre mais qui a un bon fond. En passant, il a un tas de petits côtés énervants : par exemple pourquoi code-t-on dans l’ordre :

SELECT
FROM
WHERE

alors qu’en toute logique, si on y réfléchit, la ligne SELECT est la projection finale du résultat et que l’on devrait écrire :

FROM
WHERE
SELECT

(Dommage que SQL ait avalé Quel et ISBL, autrement mieux conçus). En termes d’effort, c’est surtout la théorie relationnelle qui mérite que l’on transpire, qu’il s’agisse de la partie structurelle, de la partie manipulation ou de la partie intégrité. Pour être certain que l’on a compris cette théorie, on doit pouvoir expliquer la définition formelle du Modèle relationnel qui repose sur cinq composants :

1. Une collection non limitée de types scalaires (dont le type Booléen).
2. Un générateur de type Relation et l’interprétation attendue des types de relations générés par ce moyen.
3. Les mécanismes pour définir des variables relationnelles du type de relation voulu.
4. L’opération d’affectation relationnelle permettant d’affecter des valeurs à ces variables.
5. Une collection non limitée d’opérateurs relationnels génériques, pour produire des valeurs de type relation à partir d’autres valeurs de type relation.

Je ne fournis pas la réponse ici, car il est plus profitable que chacun creuse le sujet et transpire à son tour.

Vous évoquez les formes normales : je dirai qu’elles ne sont pas l’exclusivité du Modèle Relationnel de Données. Certes, ce sont des mathématiciens, des théoriciens du relationnel qui se sont préoccupé du sujet : Ted Codd, Raymond Boyce, Jorma Rissanen et last but not least Ronald Fagin (qui a démontré que par le mécanisme de projection/jointure sans perte, on ne pouvait aller au-delà de la 5NF (ou PJ/NF), que l’on aurait dû appeler FNF pour Fagin Normal Form, mais le garçon est un modeste). Cela dit, ce qui vaut pour une table vaut pour une entité-type, une association-type, une classe, à la limite pour un record, un fichier : toutes choses dotées d’attributs (ou propriétés, au choix). Et l'on sait les riques que l'on encourt à se passer de la normalisation.

Citation:

il faut avoir une vision objet où autrement dit un modèle objet.

Qu’est-ce qu’une vision objet ? Existe-t-il une définition formelle du Modèle objet qui tienne en quelques lignes, comme celle que j’ai fournie du Modèle relationnel (et que l'on doit à Chris Date) ? Si vous avez cela en magasin, je suis preneur !

Citation:

Les performances des SGBDRs augmentent mais essentiellement comme la puissance des serveurs qui les supportent

Il est évident que passer d’une machine de 90 mips à une machine de 900 mips est bon pour la performance des applications. Mais le gain est loin d’être linéaire. Si on est IO/Bound, on risque d’être déçu d’avoir investi beaucoup d’heuros pour un rendement qui peut être médiocre... A quoi bon une puissance CPU permettant de battre le record du nombre de décimales calculées de PI si c’est pour qu’elle ait un faible rendement, à cause de tombereaux d’entrées/sorties ? C’est là qu’est le défi, réduire drastiquement ces E/S et la conjugaison de l’identification relative au niveau conceptuel, de la normalisation, d’une bonne connaissance de l’algèbre relationnelle et du métabolisme des données, des index clusters (au sens DB2 du terme) et du partitionnement, est un facteur décisif pour la performance. Le mariage de raison de la sémantique et de la tuyauterie peut donner de beaux fruits.

Citation:

La taille des bases de données reposant sur un SGBDO est en général relativement faible

J’en reste aux SGBDR car comme je l’ai dit, je les ai bien secoués (au moins l’un d’entre eux...) et n’ai jamais été déçu. Mais leur pratique sans connaissance profonde du Modèle relationnel peut être très délicate. Grâce à celui-ci, j’ai pu aider les concepteurs à produire des MCD de deux mille entités-types avec des tables dépassant les cent millions de lignes, et ça tourne comme une horloge en production. Bien sûr il y a des petits problèmes par-ci par-là, mais rien de méchant. Sans cette connaissance profonde du Modèle relationnel je ne sais pas où j’aurais été nager et avec quelle rapidité on m’aurait flanqué à la porte.
19/05/2012, 11h47
begooden-it

Je déterre ce post et présente mes plus plates excuses pour ce fait, mais je trouve très marrant que personne ne parle d'Informix dans toute cette discussion :-)
Parti pris, oubli volontaire, oubli involontaire ou méconnaissance ?